As may be known, a CAP file is a file including one or more applets intended to be downloaded into an IC Card. Hereinafter, a brief explanation of the steps involved in the generation of the CAP file and its downloading into the IC Card are given.
A software programmer generates a CAP file by coding one or more java applets, including at least a java class, compiling the java class into a .class file, and converting the .class file into a CAP file, intended to be downloaded into the IC Card.
The steps of coding and compiling the java applet, as well as the step of converting it into a CAP file, are executed in a conventional way, for example, through a java programming environment installed in a programming device. The device may include an editor for coding the java applets, a compiler for compiling the .class files, and a converter for converting the CAP file.
With reference to FIG. 1, the downloading of the CAP file 3 from a card terminal 2 to an IC Card 1 is schematically represented. The IC Card 1 includes a platform for executing applets, not shown because it is conventional. More particularly, the platform includes a hardware platform based on the circuitry and electric components, and a software platform, including service programs that support the execution of applets.
The software platform may include a java platform. The java platform may include an installation program 4 for extracting the applets from the CAP file 3 and for storing them in a memory portion 5 of the IC Card 1, and a java virtual machine 6 for execution of the applets.
More particularly, the installation program 4 receives the CAP file 3 from the card terminal 2 and prepares the applets to be executed by the java virtual machine 6. The java virtual machine 6, substantially, is generally not aware of the CAP file 3 because it executes the applets already prepared for execution by the installation program 4.
The downloading of the CAP file 3 from the terminal 2 to the IC Card 1 is executed by an authorized IC Card issuer that is responsible to release only IC Cards compliant with precise specifications. The CAP file is prepared by the software programmer, also known as a CAP file provider, and delivered by the CAP file provider to the CAP file issuer for downloading. The IC Card manufacturer may also be the CAP file provider so that the IC Card, together with a set of applets included in the corresponding CAP file, is provided by the IC Card manufacturer to the IC Card issuer.
More particularly, according to international standard specifications, for example, the 03.48 specification for the mobile word or the GlobalPlatform specification, downloading the CAP file into the IC Card must typically respect some requirements, including:                1—allowing only the authorized CAP file issuer to download the CAP file 3 into the IC Card 1;        2—recognizing that data corruption occurred during I/O communication between the terminal 2 and the IC Card 1; and        3—avoiding disclosure of the CAP file 3 during I/O communication.        
Such requirements are generally respected by introducing the following security in the communication between the terminal 2 and the IC Card 1:                1—performing a mutual authentication between the IC Card 1 and the IC Card issuer;        2—adding an integrity control check to the CAP file 3 received by the IC Card 1; and        3—encrypting the CAP file 3 before transmission.        
FIG. 2 schematically represents the steps involved in the downloading of the CAP file 3 when the security described above is provided. More particularly, a secure protocol 7 is used by the IC Card issuer for encrypting the CAP file 3 in an encrypted CAP file 3a, before the downloading of the CAP file 3 from the card terminal 2 to the IC Card 1.
The same secure protocol 7 is used inside the IC Card 1 for decrypting the CAP file 3a into the CAP file 3. The decrypted CAP file 3 is then processed by the installation program 4, as already described with reference to FIG. 1. More particularly, the security is implemented through a transport protocol based on cryptographic keys stored in the IC Card 1 by the IC Card manufacturer and communicated by the IC Card manufacturer to the IC Card issuer.
Even if the above described security adds a certain protection to the CAP file 3, some drawbacks still limit such protection, because, when the CAP file 3 is delivered by the IC Card provider to the IC Card issuer, it is subject to intercepting and copying. More particularly, an intercepted CAP file could be reverse engineered so that the corresponding code of the applets is discovered, thus resulting in damage for the IC Card provider.
In fact, especially when the IC Card manufacturer is the IC Card provider, many efforts are involved to provide the IC Card 1, together with a complete set of applets included in the CAP file 3. Moreover, even if the CAP file is not reverse engineered, and the code of the applets is not discovered, another problem remains because the CAP file 3 may be directly downloaded and installed into an IC Card different to the IC Card 1 provided by the IC Card manufacturer. In fact, due to the portability of the java applets, the applets included in the CAP file 3 can be installed substantially into any IC Card provided with a java platform, resulting also in this case in a great damage for the IC Card manufacturer.
The problem is that of providing a method for protecting the CAP file for an IC Card so that the applet included in the CAP file can be executed only into a specific IC Card provided by a specific IC Card manufacturer, avoiding a downloading and installation of the CAP file into a third party IC Card, the method also being able to prevent a reverse engineering of the CAP file intended to discover the code at the base of the applets.